Is support for these algorithms a new requirement or are they already used somewhere?

Hello HERMABE,
It is a new requirement for a compilation purpose for a NXP application.

Excuse me for my ignorance, but why would a kconfig dependency for "a NXP application" go into the Bluetooth subsys crypto kconfig?

Hello HERMABE, It is a new requirement for a compilation purpose for a NXP application.

If these algorithms are not in use by the crypto parts of the bluetooth subsystem these selects dont belong here.

Hello HERNABE,
I have to compile the tests/bluetooth/tester application for example.
Because PSA mbedtls flags added require other prerequisites, i propose to update the tests/bluetooth/tester/Kconfig file by adding the following line :
# Config options for NXP application
osource "${ZEPHYR_BASE}/tests/bluetooth/tester/Kconfig.nxp"

The advantage of this method is there is no impacts on the application, even if the NXP files are not present thanks to the osource "${ZEPHYR_BASE}/xxx" included in the Kconfig file.

osource definition :
It works just like source, but it doesn't throw an error if the file doesn't exist. This is useful when you want to include a Kconfig file only if it’s present, such as in optional modules or configurations.

@alwa-nordic,
you are ok with my proposal ?

It is a bit weird to add a reference to a file that doesnt exist in-tree. If you anyway have a fork of zephyr, can you not just add it to the application prj.conf?

It looks like PSA_WANT_ALG_ECB_NO_PADDING is not used so it should be removed. And we depend on the PSA API, not MBEDTLS, so those selects should probably go somewhere else too

@alwa-nordic this is correct, but as of now there is no way to tell "I need crypto support" and then let Zephyr figure out if this kind of support is to be provided through Mbed TLS or TF-M. This is why we have these kind of select in Zephyr codebase. I agree that this is something we might want to fix sooner or later.

For the record, speaking of the PR, to the best of my knowledge none of these crypto algs are required for BT/BT-LE.

It is a bit weird to add a reference to a file that doesnt exist in-tree. If you anyway have a fork of zephyr, can you not just add it to the application prj.conf?

Hi Hermabe,
We have to add the flags in a Kconfig file, hence the proposed solution with the Kconfig.nxp.
If Kconfig.nxp is weird, a possibility would be to replace nxp by another key word as Kconfig.custom for example ?

What I meant was that it is weird that upstream zephyr references a file that only exists in a fork of zephyr. Can the sourcing of the kconfig file be added in the fork instead? I see no reason to have osource here since the file will not be found in the zephyr tree.

This zephyr/subsys/bluetooth/crypto/Kconfig file should enable only algorithms that are explicitly used in zephyr/subsys/bluetooth/crypto¹. Computing prerequisite kconfigs should be the responsibility of the PSA subsystem. I expect it should go in a board-specific file in zephyr/modules/mbedtls.